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Lời mở đâu 


Hello bạn hiền, rất vui được gặp bạn tại những dòng chữ này. Có thể 
bạn hữu duyên hay hữu ý thì những gì bạn bắt gặp được trong tập tài liệu 
này cũng tạm gọi là những kiến thức nho nhỏ cơ bản, vừa đủ hành trang 
để cho bạn có thể vận dụng hay ít nhiều gì cũng có thể trở thành một 
fresher tương lai chính hiệu trong ngành Tesíing. Đó chính là điều mà tui 
đã luôn ấp ủ từ lâu. 


Nếu như “level” của bạn đã hơn fresher một chút rồi thì cũng không 
sao, biết đâu nó lại giúp mình củng cố được những kiến thức mà trong 
suốt quá trình làm việc, mình mãi chạy theo task sếp giao, hay những lần 
deadline của hôm qua mà cứ ngỡ là hôm nay mà mình không còn nhớ 
đến sự tồn tại của nó nữa. Thì tập tài liệu này sẽ giúp bạn nhớ về nó một 
lần nữa III 


Bạn đã sẵn sàng chưa? 


Nếu chưa thì mời bạn lật sang trang tiếp theo nhé l!I 


Lời giới thiệu 


Rong ruồi trên con xe Wave trong suốt 3 năm trời kể từ ngày ra 
trường, cuộc đời làm sale vừa vui vừa cực, nó cho tui nếm trải được 
những cái nóng gắt của nắng giữa trưa, những cái lạnh ướt của ngọn mưa 
rào, những nụ cười ấm áp của các chủ tiệm tạp hóa, cũng như những ánh 
mắt ngờ vực khi mình chào sản phẩm của công ty... Đôi lúc khiến cho 
mình phải suy nghĩ, có cách nào một dân sale như mình mà có thể làm 
một công việc văn phòng không? Ít ra cái không khí máy lạnh nó cũng làm 
cho mình xua tan đi những cái nóng, né được những cơn mưa, nhưng để 
đổi lại thì thời gian mình không được tự do đi lại nữa, mà phải chịu trận với 
quỹ thời gian là 8 tiếng/ ngày. Nghĩ đến đây thôi, tui lại cảm thấy mông 
lung... 


Nhưng, tui vẫn quyết định tìm hiểu trên khắp các diễn đàn tìm việc có 
uy tín, cũng tìm ra được vài công việc văn phòng như kế toán, làm chứng 
từ số sách... Rồi cũng có thử phỏng vấn, nhưng chuyên môn không đủ thì 
cũng không tìm được công việc mà mình đã chọn. 


Đó là chưa kể tui đã từng thử nhiều công việc lặt vặt linh tinh nhưng 
rồi cũng bỏ giữa chừng... 


Rồi trong một lần rất tình cờ, tui được mấy đứa em nó bày: “Sao anh 
hai không đi học Tester đi, công việc này đang cần người dữ lắm!” Lúc này 
tui làm gì biết Tester là gì? cũng chưa có một khái niệm nào rõ ràng về nó 
cả. Lại như một thói quen, lên mạng search tìm đủ kiểu cũng hiểu được sơ 
sơ. Trong đầu lại lóe lên suy nghĩ, người ta học 4 năm trời thì mình làm gì 
có cửa. Nhưng tui vẫn nhắm mắt tìm hiểu tiếp tục, thì vô tình tìm được một 
khóa học ngắn hạn ở trường Đại Học Tự Nhiên. Một tia hi vọng lại lóe lên 
và quyết định đăng ký... Và con đường Tester từ đó được mở rộng... 


" ” 


Và tui xin nói lại, đây chỉ là một “tập tài liệu”, chứ không phải là 
sách gì hết nhaI 


CHƯƠNG 11: TUI ĐÃ TIẾP CẬN SOFTWARE TESTING NHƯ THẺ 
NÀO? 


Hào hứng, nôn nao, chờ đợi... chính là những cảm xúc thực sự lúc 
đó của tui. Tui có lại được những cảm giác hoàn toàn mới về thời cắp sách 
tới trường, về những kiến thức mà mình sắp sửa được thỉnh giáo. Nhưng 
tui không hoàn toàn thấy áp lực, vì tui biết đây chỉ là ngắn hạn, và cũng 
không phải áp lực thi cử, trường lớp. 


Đầu tiên, thì tui sẽ được học về những từ chuyên ngành cơ bản 
trong giới công nghệ thông tin hay còn gọi tắt là IT. 


Algorithm: Thuật toán 

Application: Ứng dụng 

Browser: Trình duyệt 

Bug: Lỗi <= Tester gặp con Bug như gặp được tiền :=)))) 
Cookies: Không phải là cái bánh Cookies đâu nhé :=)))) 
Cursor: Con trỏ 

Database: Cơ sở dữ liệu 

File: Tập tin 

Folder: Thư mục 

Hard Drive: Ö cứng 

Hardware: Phần cứng 

lcon: Biểu tượng 

Network: Mạng 

Server: Máy chủ 

Source Code: Mã nguồn 

Scopeí goal: Phạm vi/ Mục tiêu 

Network administrators: Quản trị mạng 

Software developers: Nhà phát triển phần mềm 

Web developers: Nhà phát triển Web 


Khi mà được biết đến những từ này thì điều đầu tiên tui nghĩ, Ò hy 
vọng vốn tiếng anh của mình sẽ được cải thiện nhiều đây!!!. Thực ra vẫn 
còn rất nhiều từ thông dụng, khi nào bạn đi làm, bạn sẽ được tiếp xúc nó 
một cách chân thật nhất. 


Rồi tiếp theo là những gì cơ bản nhất của kiểm thử chẳng hạn như là 
“Vòng đời phát triển phân mêm" (Soffware Development Life-Cycle) là gì? 
Nghe như là vòng đời phát triển của một con sâu ấy nhỉ, vì tui vừa được 
học từ Bug xong nên có phần liên tưởng hơi sai sai. Thôi kệ, bỏ qua nó đi. 
Giờ dô định nghĩa nha. Nó chính là một cách tiếp cận có hệ thống và có 
trật tự để giải quyết các vấn đề liên quan đến hệ thống phần mềm hay nói 
cách khác nó là một cấu trúc đối với sự phát triển của một sản phẩm phần 
mềm. Tuỳ thuộc vào các loại mô hình phát triển phần mềm khác nhau mà 
các giai đoạn (phase) sau có thể được sắp xếp và tổ chức khác nhau. 


Nói đến đây, bạn sẽ thắc mắc có bao nhiêu loại mô hình phát triển 
phần mềm? Tui sẽ liệt kê ngay và luôn: 


- MÔ HÌNH THÁC NƯỚC (WATERFALL MODEL) 
- MÔ HÌNH SPIRAL (SPIRAL MODEL) 

- MÔ HÌNH CHỮ V (V MODEL) 

- MÔ HÌNH CONCURRENT 

- MÔ HÌNH AGILE (SCRUM) 


Trong tập tài liệu này tui sẽ giới thiệu đến bạn mô hình mà hiện nay 
đa phần các công ty sẽ sử dụng đó là Mô hình Agile, những mô hình còn 
lại tui sẽ không nói tới vì nó sẽ làm bạn rối và khó hiểu thêm thôi. 


Agile là một phương pháp phát triển phần mềm linh hoạt để làm sao 
đưa sản phẩm đến tay người dùng càng nhanh càng tốt và được xem như 
là sự cải tiến so với những mô hình cũ. Mô hình này được ứng dụng với 
bất kỳ loại hình dự án nào, nhưng cần sự tham gia và tính tương tác của 
khách hàng. Được sử dụng khi khách hàng yêu cầu chức năng sẵn sàng 
trong khoảng thời gian ngắn. 


Scrum là 1 dạng của mô hình Agile và là framework phổ biến nhất 


khi thực hiện mô hình Agile. Scrum là mô hình phát triển lặp đi lặp lại. 
Những khoảng lặp cố định thường kéo dài 1, 2 tuần được gọi là Sprint. 
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Chia các yêu cầu ra làm theo từng giai đoạn. Mỗi giai đoạn (sprint) 
chỉ làm 1 số lượng yêu cầu nhất định. 


e Mỗi một sprint kéo dài khoảng từ 1 tuần đến 4 tuần (ko dài hơn 1 
tháng). 

e Đầu sprint sẽ lên kế hoạch làm những yêu cầu nào. Sau đó, sẽ thực 
hiện code và test. Cuối sprint là 1 sản phẩm hoàn thiện cả code lẫn 
test có thể demo và chạy được. 

e Hoàn thành sprint 1, tiếp tục làm sprint 2, sprint... cho đến khi hoàn 
thành hết các yêu cầu. 

e Trong mỗi 1 sprint thì sẽ có họp hàng ngày — daily meeting từ 15 — 
20 phút. Mỗi thành viên sẽ báo cáo: Hôm qua đã làm gì? Hôm nay 
tiếp tục làm gì? Có gặp khó khăn gì không? 

e Scrum là mô hình hướng khách hàng (Customer oriented). 


Đến đây, thì bạn đã có hình dung được công việc trong tương lai chưa? 
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CHƯƠNG 2: TÔNG QUAN VỀ TESTER VÀ CÔNG VIỆC CHÍNH 


Đề mà kiểm thử một phần mềm thì cần phải có người làm công việc 
đó, thì không ai khác chính là bạn, những người đang khao khát và cầm 
cuốn tập tài liệu này trên tay, thì mình sẽ có một cái name chung là Tester, 
ở một số công ty khác thì người ta sẽ gọi là QA/ QC (tui sẽ nói rõ hơn ở 
những chương sau). Vậy thì nhiệm vụ của Tester sẽ là gì, đọc tiếp nè: 


Đầu tiên, Tester sẽ là người quản lý chất lượng sản phẩm. Đảm 
bảo phần mềm hoạt động đúng với requirement (docs) được đề ra. Quan 
trọng nhất là phải luôn luôn tìm ra các khiếm khuyết (lỗi hay còn gọi là bug) 
để cải thiện chất lượng sản phẩm trước khách hàng hoặc công ty, vì nếu 
như bạn không tìm thấy được bug, mà công ty hoặc khách hàng là người 
phát hiện ra, thì bạn sẽ bị điểm trừ. Hãy nhớ nguyên tắc này nhé. Nó còn 
quan trọng hơn cả “Nguyên tắc kiểm thử phân mêm” mà bạn sắp sửa 
được giới thiệu tiếp theo sau đây đói 

Đọc đến đây, bạn thử tưởng tượng làm thế nào để lúc nào mình 
cũng có thể tìm ra được những khiếm khuyết, những con bug của sản 
phẩm phần mềm không? Tui xin dừng lại khoảng là 5s để bạn thử liệt kê ra 
nhé... 


Rồi, hết 5s, tui sẽ tiếp tục nói cho bạn biết những cách mà đơn giản 
nhất để có thể lúc nào cũng tìm được bug nhé. Bạn phải: 


e Hiểu và trải nghiệm nghiệp vụ của hệ thống phần mềm công ty. 

e Review sản phẩm theo hướng User và hướng người tạo ra sản 
phẩm. 

e Tạo các kiểm tra để đánh giá chất lượng: Test-plan, test-case, 
report... 

e Phối hợp với các team khác để cùng thực hiện mục đích chính là 
nâng cao chất lượng sản phẩm. 

e_ Phản hồi các vấn đề liên quan đến chất lượng phần mềm. 
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Sau này bước vào công việc thực tế rồi, bạn sẽ hiểu rõ hơn về 
những cách này, giờ thì chúng ta sẽ đi vào phần trách nhiệm chính của 
Tester nhé: 


4.Tìm ra vấn đề: 

-Phát hiện ra bug 

-Nhận định được phần nào có nguy cơ có bug cao (rủi ro) 
-Nhận định được điểm yếu của dự án 

-Tìm ra nhiều cách hay/ hiệu quả để tìm ra bug 


2. Thông báo vấn đề 

-Report bug 

-Report về quá trình testing 

-Đánh giá và report độ ồn định của dự án/ chương trình 

-Giải thích và mô tả lại các bước để tái tạo bug đề: 

+ Dev có thể dựa vào đó để check và fix nó 

+ Bộ phận liên quan biết được và không lặp lại lỗi đó khi mà dev chưa fix 
kịp. 


Nãy giờ tui quên giới thiệu tới bạn biết như thế nào gọi là “Kiểm thử 
phân mêm”. Nó chính là quá trình đánh giá một hệ thống hay các thành 
phần của nó với mục đích tìm xem liệu hệ thống có đáp ứng các yêu cầu 
đã được chỉ định hay không. Nói một cách đơn giản, kiểm thử được thực 
hiện trên một hệ thống để xác định lỗi hoặc các yêu cầu đang bị thiếu 
hay trái ngược với các yêu cầu thực tế đã được đề ra. 


Vậy khi nào thì chúng ta bắt đầu kiểm thử, đó chính là lúc bạn được 
công ty ứng tuyển đi làm đó. Giỡn thôi, kiểm thử có thể bắt đầu từ giai 
đoạn khi có những yêu cầu từ khách hàng cho đến khi triển khai phần 
mềm. Ngoài ra, kiểm thử sớm làm giảm chỉ phí và thời gian để xây dựng 
lại và sửa lỗi trước khi bàn giao sản phẩm cho khách hàng. Nếu như có 
bắt đầu thì phải có kết thúc chứ nhỉ, vậy câu hỏi tiếp theo được đặt ra là 
khi nào là lúc thích hợp để mình ngừng kiểm thử, bạn đừng nghĩ đó là lúc 
nghỉ việc nha. Nếu bạn lỡ nghĩ như vậy thì mình phải tiếp tục đọc tiếp tập 
tài liệu này nhé :=))))) 
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Chúng ta sẽ phải kết thúc kiểm thử khi: 


e Thời hạn hoàn thành kiểm thử (Testing Deadlines). 

e Thực thi tất cả các testcase đã đề ra. 

e Hoàn thành các chức năng và bao phủ toàn bộ các yêu cầu đã được 
đề ra. 

e Tỉ lệ lỗi ở dưới một mức nhất định và không có lỗi nghiêm trọng nào 
được tìm thấy. 

e_ Quyết định của người quản lý dự án. 


Vậy chúng ta tiếp tục đến với lý do tại sao phải kiểm thử nhé, phần 
này nó hơi lý thuyết dài dòng, bạn nhớ đọc kỹ đề hiểu nha: 


- Kiểm thử phần mềm là khâu vô cùng quan trọng trong quá trình 
phát triển 1 sản phẩm công nghệ. Nó chỉ ra những lỗi và sai sót đã được 
thực hiện trong các giai đoạn phát triển. 

- Đó là điều cần thiết vì nó đảm bảo độ tin cậy của khách hàng và sự 
hài lòng của họ với ứng dụng mà mình tạo ra. 

- Nó đảm bảo chất lượng của sản phẩm. Sản phẩm chất lượng được 
giao cho khách hàng khiến họ tin tưởng hơn. 

- Kiểm thử phần mềm là cần thiết vì nó sẽ giúp cung cấp các ứng 
dụng phần mềm cho khách hàng phân phối được hưởng sản phẩm chất 
lượng cao hoặc chi phí bảo trì ứng dụng phần mềm thấp hơn, tiết kiệm 
hơn và do đó dẫn đến hiệu quả cao nhất và đáng tin cậy hơn. 

- Kiểm thử phần mềm giúp tăng hiệu suất công việc do giảm được tối 
đa thời gian để tìm lỗi trên ứng dụng phần mềm hoặc sản phẩm nhiều lần. 

- Điều quan trọng là nó đảm bảo rằng ứng dụng không dẫn đến bắt 
kỳ lỗi nào, hạn chế tối đa những tốn kém trong tương lai hoặc trong các 
giai đoạn sau của quá trình phát triển sản phẩm. 


Mục đích của kiểm thử phần mềm là gì, có phải là để kiểm tra phần 
mềm đó hoạt động có tốt hay không, phần mềm đó có nhiều bug hay 
không, hay chỉ đơn giản là phần mềm này hay hay dở... Ngoài những cái 
mà tui vừa nói trên thì nó còn có thêm những kiến thức chuyên môn sau: 

- Tìm ra những lỗ hồng / bug mà các lập trình viên tạo ra trong quá 
trình code. 


- Đảm bảo sản phẩm tạo ra đạt chất lượng cao nhất có thê. 
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- Hạn chế tối đa lỗi có trong sản phẩm. 

- Đề đảm bảo rằng sản phẩm cuối cùng đưa ra thị trường hoặc giao 
đến khách hàng đáp ứng đúng nhu cầu và mong muốn của người sử dụng. 

- Kiểm thử phần mềm sẽ giúp hoàn thiện các ứng dụng phần mềm 
hoặc sản phẩm so với yêu cầu kinh doanh và người sử dụng. 


CHƯƠNG 3: 7 NGUYÊN TÁC KIÊM THỬ PHÀN MÈM 


Bài học nào cũng vậy, cuộc chơi nào cũng thế, đều phải có những 
nguyên tắc cơ bản riêng của nó, nếu như bạn đã hiểu được luật lệ, nguyên 
tắc của nó rồi, thì việc vận dụng hay sử dụng nó sẽ dễ đạt được kết quả tốt 
nhất có thê. 


Bạn có tò mò về con số 7 không, tại sao không phải là một con số 
khác mà phải là con số 7 ?22 Tui cũng không biết nữa, có thể là từ nhiều 
nguyên tắc được tóm lược và chỉ còn 7 nguyên tắc chính và cơ bản nhất 
cho người mới bắt đầu, chắc là vậy... Nếu bạn bắt gặp hay search thử trên 
goodle thì sẽ thấy được những dòng chữ nhảy múa nhẹ nhàng trong 7 
nguyên tắc này, nhưng khi bạn đọc những dòng chữ dưới đây thì nó đã 
được tui tiếp tục rút gọn thêm một cách ngắn nhất có thể mà vẫn bảo đảm 
nguyên vẹn ý nghĩa của nó. Yên tâm nha! bắt đầu dô nào. 


—I-)\(©e0040) 
TẮC 
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NGUYÊN TÁC 1: Sự hiện diện của lỗi 

- Phần mềm lúc nào cũng có lỗi => cố gắng hạn chế ít lỗi nhất có thể. 
NGUYÊN TÁC 2: Kiểm tra càng sớm càng tốt 

- Đừng đợi khi sản phẩm hoàn thành thì mới test. 


- Hãy phân tích nó ngay từ khi nhận được spec/ requirement - tìm lỗi ở giai 
đoạn này cũng là một cách kiểm thử đem lại hiệu quả tốt cho sau này. 


NGUYÊN TÁC 3: Kiểm thử toàn bộ là không thể 


- Chỉ nên tập trung test những phần quan trọng/ những phần cần test trong 
Sprint. 


NGUYÊN TÁC 4: Lỗi được phân bó tập trung 

- Nếu như phát hiện lỗi ở Function/ Chức năng nào thì sẽ tập trung test kĩ 
ở chỗ đó. 

- Áp dụng: Nguyên tắc tổ gián, nguyên tắc 80%-20%, nguyên tắc những 
tính năng related gần nhát. 

NGUYÊN TÁC 5: Nguyên tắc nghịch lý thuốc trừ sâu 


- Luôn thay đổi cách test để luôn tìm ra lỗi mới, không nên áp dụng 1 cách 
test/ test theo 1 bộ testcase duy nhất. 


NGUYÊN TÁC 6: Kiểm thử theo ngữ cảnh độc lập 


- Tùy vào trường hợp, hoàn cảnh/ đặc thù của tính năng mà có cách kiểm 
thử hợp lý. 


NGUYÊN TÁC 7: Quan niệm “hết lỗi” 
- Kiểm thử phần mềm không chỉ đề hết lỗi, mà còn phải đáp ứng được nhu 


cầu của khách hàng. 


Trong 7 nguyên tắc này, thì bạn thấy nguyên tắc nào là dễ nhớ nhất 
và dễ hình dung nhất? 
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CHƯƠNG 4: PHÂN BIỆT QA/ QC/ TESTING 


QA (Quality Assurance): Là người quan tâm đến quá trình tạo ra 
sản phẩm. Bằng cách bảo đảm sản phẩm được tạo ra đúng với yêu cầu 
ban đầu. 


VD: Yêu cầu ban đầu là để tạo ra được một phần mềm đọc sách, thì 
phải có bước †1 là sign in/ sign up, bước 2 là tìm sách, bước 3 là lưu sách. 
Thì QA có vai trò là giám sát và bảo đảm cho phần mềm phải đủ và đúng 
thứ tự 3 bước này. Nếu như phần mềm được là ra với bước 1 là tìm sách, 
bước 2 là sign in/sign up, bước 3 là lưu sách... thì điều này vẫn tạo ra 
được 1 phần mềm đủ các tính năng nhưng nó không đáp ứng được yêu 
cầu ban đầu được đề ra. 


Bạn đã hiểu chỗ này rồi phải không? 


QC (Quality Control)/ Tester: Là người quan tâm đến sản phẩm 
cuối cùng được hoàn thành. Bằng cách test sản phẩm sau khi nó hoàn 
thành. 


VD: Sau khi sản phẩm đã được hoàn thành đúng với yêu cầu ban 
đầu, thì QC/ Tester sẽ đi test từng tính năng như sign in/ sign up, tìm sách, 
lưu sách dựa vào spec/ doc. 

Testing: Được thực hiện sau khi sản phẩm/ tính năng được hoàn 
thành. 


VD: Là hoạt động để phục vụ cho công việc test như lập kế hoạch, 
Test Plan, Test Case, thực thi test... 
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CHƯƠNG 5: CÁCH CƠ BẢN XÁC ĐỊNH KHI LOG BUG 

Khi phát hiện ra được một con Bug nào đó, thì chắc hẳn bạn sẽ thắc 
mắc, làm sao để mình diễn tả cho người khác hiểu về con Bug này. Thì ở 
chương này tui sẽ tóm gọn trong 4W và 1H 


L3:0(o(cÐ2 (e2). (4 Nho - 7. - 


What -Bug này là bug gì,độ nghiêm 
U9)/1°N-/ 0. 0/0. /0/00/0./0-0./-.-1. 
4 


` =Xác định lỗi ở đâu,trên mô 
0049/10, 1-20. /-1-5/(0008-1/-)./.1-100/0-i-7-i-1-) 
01 8/2-)/0/-1°91-'08.1-i..08,.-i-) 


—_—_ -Bug xảy ra khi nào (nghĩa là 
10 6-1/11-1./0//00/./1-0-1//9/-1,- 0/00 ÔÓÔO 0V - 





Bạn chỉ cần đọc sơ qua để hiểu thôi, chứ về phần WHAT, trong tập 
tài liệu này sẽ có 1 chương để nói về “Những loại bug thường gặp”, thì khi 
đó bạn sẽ hiểu được nó thuộc dạng Bug loại gì, rồi cũng sẽ có một chương 
nói về “Độ nghiêm trọng, độ ưu tiên” của từng con Bug. Nên bạn cứ yên 
tâm mà đọc tiếp nhé! Bây giờ thì chúng ta tiếp tục nào... 
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CHƯƠNG 6: CÁC CÁP ĐỘ TRONG KIÊM THỬ PHÀN MỀM (Test 
Level) 
Ở đây sẽ có tất cả là 4 cấp độ đi từ thấp đến cao: 
1/ Kiểm thử đơn vị (Unit Test) 
2/ Kiểm thử tích hợp (Integration Test) 
3/ Kiểm thử hệ thống (System Test) 
4/ Kiểm thử chấp nhận người dùng (User Acceptance Test) 
Chúng ta sẽ đi dzô chỉ tiết từng cấp độ nhé 
-Đầu tiên sẽ là KIÊM THỬ ĐƠN VỊ 
Kiểm thử đơn vị là cấp độ kiểm thử cơ bản, thực hiện test từng 
module nhỏ trong hệ thông. 


Kiểm thử đơn vị có thể được thực hiện tách biệt với phần còn lại 
của hệ thống tùy thuộc vào mô hình vòng đời phát triển được chọn cho 
ứng dụng cụ thể đó. 


Mục đích: đề xác nhận mỗi thành phần của phần mềm thực hiện 
đúng với thiết kế 

Kiểm thử đơn vị thường do lập trình viên thực hiện 
-Thứ hai là KIÊM THỬ TÍCH HỢP 


Kiểm thử tích hợp có nghĩa là kiểm thử kết hợp. Một dự án phần 
mềm được kết hợp bởi nhiều module riêng lẻ khác nhau và được code 
bởi nhiều lập trình viên khác nhau. Chính vì thế kiểm thử tích hợp là 
tích hợp kiểm tra các module riêng lẻ với nhau thành một nhóm 

Tích hợp kiểm tra việc truyền dữ liệu giữa các module, tích hợp kiểm 
tra các hàm lại với nhau, các màn hình với nhau theo từng module 
hoặc theo chức năng 

Mục đích: đễ đàm bảo rằng hệ thống tích hợp đã sẵn sàng để thử 
nghiệm hệ thống 

Kiểm thử tích hợp được thực hiện sau khi kiểm tra đơn vị và trước 
khi kiểm tra hệ thống 

Integration testing được thực hiện bởi một người thử nghiệm cụ 
thể hoặc một nhóm kiểm thử 


-Thứ ba là KIÊM THỬ HỆ THÓNG 


System Testing là thực hiện kiểm thử một hệ thống đã được tích 
hợp hoàn chỉnh đề xác minh rằng nó đúng yêu cầu của phần mềm. 


Kiểm thử hệ thống nằm trong phạm vi kiểm thử hộp đen và do đó 
không yêu cầu kiến thức về thiết kế bên trong của mã hoặc logic. 


Kiểm thử hệ thống thường là thử nghiệm cuối cùng để xác minh 
rằng hệ thống được phân phối đáp ứng các đặc điểm kỹ thuật và mục đích 
của nó. 

Kiểm thử hệ thống nên thực hiện kiểm thử chức năng và phi chức 
năng và được thực hiện bởi Tester. 


-Thứ tư là KIÊM THỬ CHÁP NHẬN NGƯỜI DÙNG 

Sau khi kiểm tra hệ thống đã sửa tất cả hoặc hầu hết các lỗi, hệ 
thống sẽ được gửi đến người dùng hoặc khách hàng để kiểm tra chấp 
nhận. 

Về cơ bản kiểm thử chấp nhận cũng khá giống kiểm thử hệ thống 
nhưng được thực hiện bởi khách hàng. 

Muc đích: đảm bảo phần mềm đáp ứng đúng yêu cầu của khách 
hàng. Sản phẩm nhận được sự chấp nhận từ khách hàng/ người dùng 
cuối. 

Kiểm thử chấp nhận được chia thành 2 mức khác nhau: 

Kiểm thử alpha: được thực hiện tại nơi phát triển phần mềm bởi 
những người trong tổ chức nhưng không tham gia phát triển phần 
mềm. 

Kiểm thử beta: được thực hiện tại bởi khách hàng/ người dùng cuối 
tại địa điểm của người dùng cuối. 


Như vậy là Test Level của chúng ta cũng đã đi đến hồi kết rồi, và tui cũng xin 
nhắn mạnh 1 điều rằng bạn đừng nhằm lẫn nó với Test Type nhé. Chúng ta 
sẽ tiếp tục tìm hiểu tới Test Type ngay bây giờ đây !I 


CHƯƠNG 7: CÁC LOẠI TEST TRONG KIÊM THỬ PHÀN MÈM 
(Test Type) 


Như ở chương trước, tui đã giới thiệu đến bạn có 4 loại Test Level, 
thì ở chương này, Test Type sẽ được chia thành 3 loại chính: 


1/ Black Box Testing 
2/ White Box Testing 
3/ Grey Box Testing 
Đầu tiên đi vào Black Box Testing trước nhé: 


Là phương pháp test mà không cần biết bên trong code có những gì, 
thực hiện như thế nào. 


Phương pháp test này bao gồm: 


-  equivalence partitioning 

-_ boundary value analysis 

- _ all-pairs testing 

-  fuzz testing 

- _ model-based testing 

- _ traceability matrix 

- _eXploratory testing 

-  specification-based testing. 


Specification-based testing (Test dựa vào chức năng) 


Là cách test các chức năng của phần mềm dựa theo yêu cầu của 
khách hàng, các thực hiện, các Tester nhập data và chỉ thấy được kết quả 
trên màn hình. 

Specification-based testing là cần thiết nhưng không đủ để bảo đảm 
sạch budg. 

White Box Testing là phương pháp ngược lại hoàn toàn với Black 
Box Testing, vì bạn nghe cái tên thôi cũng thấy nó ngược màu với nhau 
rồi (Cái màu Đen, cái màu Trắng mà :=))))) 

Phương pháp này Tester có thể thấy được cấu trúc và thuật toán bên 
trong phần mềm. 

Loại test được dùng trong White Box Testing: 


Api testing — Kiểm tra ứng dụng sử dụng các Public API và Private API. 


KIỀN THỨC TESTER 


Còn cái còn lại, Grey Box Testing, bạn có thể hình dung như khi 
mình trộn màu trắng với màu đen lại với nhau thì nó sẽ trở thành màu xám. 
Đối với Phương pháp Grey Box Testing này cũng vậy, nó là sự tổng hợp 
của 2 phương pháp trên. Phương pháp này cho phép sử dụng cấu trúc và 
thuật toán bên trong chương trình để thiết kế testcase. Nhưng khi test thì 
Tester thực hiện như Black Box Testing. 


Đó là 3 Loại Test bạn cần phải biết, và tui vẫn xin nhấn mạnh lại lần 
nữa là bạn cần phân biệt được Các cấp độ Test (Test Level) và Các loại 
Test (Test Type) nha. Nếu không để ý thì bạn sẽ rất dễ nhằm lẫn chúng 
với nhau. 


Trước khi qua chương mới, tui cần bạn ôn lại: 


- _ Kiểm thử phần mềm là gì? Tại sao phải cần có kiểm thử? 
- _ Công việc và trách nhiệm chính của Tester? 

- - Phân biệt giữa QA/ QC và Testing? 

- _ Các nguyên tắc kiểm thử phần mềm? 

- _ Các bước xác định khi log bug? 


Nếu có giấy Note để ghi lại thì càng tốt ^^ 
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CHƯƠNG 8: CÁC KỸ THUẬT THIẾT KÉ TESTCASE 


Đây chính là phần quan trọng trong những phần quan trọng, nó giúp 
bạn quyết định được tỷ lệ Bug có được detect triệt để hay không, có bị 
miss bug nhiều hay không. Nó sẽ giúp cho bạn có cái nhìn khái quát hơn 
và nắm vững Project một cách tự tin hơn. Bạn phải đọc kỹ và nhớ nằm 
lòng những kỹ thuật này nhé, vì nó sẽ là tiền đề cho bạn tiến bộ sau này 
đó! Nhớ nhé, quan trọng lắm... 


Tui sẽ chia Kỹ thuật thiết kế testcase này thành 2 loại lớn: 
1/ Functional (Chức năng) 


2/ Non - Functional (Phi chức năng) 


Và trong từng loại lớn này sẽ được chia thành nhiều loại nhỏ tương 
ứng, giờ chúng ta sẽ vào Funcfional trước. Nó được chia thành những kỹ 
thuật nhỏ như sau: 


1/ Kỹ thuật phân lớp vùng tương đương 


Dhâm lớp ÐIO"# +. 0as9 


Là phương pháp chia các điều kiện đầu vào thành 
những vùng tương đương nhau. Tất cả các giá trị 
trong một vùng tương đương sẽ cho một kết quả 
đầu ra giống nhau. Vì vậy chúng ta có thể test một 
giá trị đại diện trong vùng tương đương. 


VD: Điều kiện nhập text vào field username có 
trong khoảng từ 6 tới 15 kí tự. Ta có các vùng 
tương đương như sau: 

- Vùng 1: Nhập ít hơn 6 kí tự => Failed 

- Vùng 2: Nhập nhiều hơn 15 kí tự => Failed 

- Vùng 3: Nhập kí tự trong khoảng từ 6 tới 15 kí tự 
=> Passcd 

- Vùng 4: Nhập số kí tự bằng đúng 6 hoặc 15 kí tự 
=> Passcd 

- Vùng 5: Không nhập kí tự hoặc kí tự không phải 
là text => Failed 
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2/ Kỹ thuật giá trị vùng biên 


Phương pháp này tập trung vào việc kiểm thử các 
giá trị biên. 


VD: Điều kiện nhập text vào field usernamne có 
trong khoảng từ 6 tới 15 kí tự. Ta có các vùng 
tương đương như sau: 

- Vùng 1: Nhập 5 kí tự (Cận biên trái) => EFailed 
- Vùng 2: Nhập 16 kí tự (Cận biên phải) => Failed 








- Vùng 3: Nhập 6 kí tự hoặc 15 kí tự => Passed 

- Vùng 4: Nhập 7 kí tự hoặc 14 kí tự => Passed 

- Vùng 5: Không nhập kí tự hoặc kí tự không phải 
là text => Failed 


3/ Kỹ thuật phân tích điều kiện ràng buộc 


^_ sàng buÔÖt 
phan tịch Giều VÊU 0 c ngpoairtÑnaljRt9 


Phương pháp này ràng buộc điều kiện giữa dữ liêu 
đầu và đữ liệu cuối, có thể áp dụng cho các trường 
hợp từ ngày “tháng /năm đến ngày “tháng /(năm 


VD: Filter danh sách học viên từ "Field ngày bắt 
đầu" đến "Field ngày kết thúc" 

- Case 1: Field ngày bắt đầu nhỏ hơn Field ngày kết 
thúc. 

- Case 2: Field ngày bắt đầu lớn hơn Field ngày kết 
thue. 

- Case 3: Field ngày bắt đầu bằng Field ngày kết 
thïec. 

- Case 4: Nhập Field ngày bắt đầu và để trống Field 
ngày kết thúc. 

- Case 5: Để trống Field ngày bắt đầu và nhập Field 
ngày kết thúc. 


Dựa vào requirement để xác định expected result 
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4I Kỹ thuật thay đổi trạng thái 


Liên quan đến việc phân tích mối quan hệ giữa 
các trạng thái và các sự kiện hoặc hành động gây 
ra sự chuyển đổi từ trạng thái này sang trạng 
thái khác. 


VD: Một danh sách học viên có 5 trang. 

- Case 1: Check các trường hợp chuyển từ trang 1 
sang trang khác và quan sát actual result có 
trùng khớp với expected result ở hiển thị trang 
mới chuyển hay không? 

- Case 2: Check trạng thái ở trang 1 khi chuyển 
qua trang 2 có trở về mặc định hay không? hay 
vẫn còn lưu những trạng thái của trang 1. 

- Case 3: Check các button: First/⁄ Previous/ 
Next/⁄ Last (Nếu có) 

- CRARS 4:... 


Thế còn Non - Functional, nó sẽ gồm những Kỹ thuật nào, mời bạn đọc 
tiếp: 
5⁄ Kỹ thuật LookK and Feel 


Nan,và,còm thỔn (feok,ond 5e” 


Phương pháp này chủ yếu nghiêng về phần design 
có dễ nhìn hay không, có dễ thấy hay không. Sữ 
đụng có đễ chịu, có cảm giác thoải mái hay 
không? 


mm": 

- Button sign-in hơi nhỏ 

- Màu field nhập username khó thấy 

- Font chữ không đồng nhất 

- Canh lề bị lệch 

- Color button bị trùng với color background 
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6/ Kỹ thuật Đoán Lỗi 


Đeów lỗt (Gm s0uessng) 


Phương pháp này không có quy trình cụ thể vì có 
tính trực giác cao và không thể dự đoán trước. 


Phương pháp chỉ phù hợp với những Tester có kinh 
nghiệm. Họ được đưa cho 1 chương trình, họ phỏng 
đoán dựa vào trực giác, dựa vào kinh nghiệm, dữ 
liệu lịch sử về các lỗi đã từng xảy ra với chương 
trình trước đó... và sau đó viết các ca kiểm thử để 
đưa ra các lỗi đó. 


7/ Kỹ thuật Phủ Định - Negative 


... _yeucMJt 


Là phương pháp cố ýÿ test ngược lại flow đúng của 
tính năng nhằm để xuất hiện báo lỗi (error 
messaøe). 


VD: 

- Để trống field Username thì sẽ không cho đăng 
nhập và báo lỗi. 

- Nhập kí tự đặc biệt ở field Password khi đăng 
ký tài khoản và báo lỗi. 

- Nhập kí tự bằng khoảng cách ở field Username 
hay Password thì sẽ báo lỗi. 

- Cố ý thao tác cho crash app, 404... 
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8/ Kỹ thuật độ hài lòng của người vkdÁc Bo cuối 
cbangMŠ mm. "Aeasgtane9 
Độ hài lồng ®””Ở („8 


Là quá trình test để xác nhận rằng một phần 
mềm đã tạo ra có hoạt động phù hợp với người 
dùng cuối hay không? 

Nó có thể được xem là test theo cách mà người 
dùng muốn sử đụng và có đáp ứng được nhu cầu 
của người dùng hay không? 


VD: App đọc sách online thì rất là tiện lợi cho 
những ai không có thời gian cập nhật sách mới 
cũng như ra nhà sách để mua từng cuốn sách về 
đọc. Nhưng để sử dụng được app này thì phải qua 
sign up/⁄ validate bằng nhiều bước rất phức tạp 
khiến người dùng cảm thấy mất thời gian cho 
việc tìm hiểu phần siợgn-up, thậm chí là không 
biết cách sign-up như thế nào. 


Đó là những kỹ thuật thiết kế testcase căn bản nhất mà bạn phải nhớ 
nằm lòng nha! Đương nhiên ngoài những kỹ thuật này, sẽ có nhiều kỹ 
thuật thiết kế testcase nâng cao hơn. Nhưng bạn chỉ cần nắm vững những 
kỹ thuật này là đủ ăn tiền rồi! Ok nha... 


Trước khi qua chương tiếp theo chúng ta sẽ lại ôn tập lại bài cũ một 
lần nhé: 
- _ Cách cơ bản để xác định khi log Bug? 


- Cấp độ Test và Loại Test. Liệt kê chỉ tiết 
-_ Và phần quan trọng nhất chính là “Kỹ thuật thiết kế testcase” 


Và tui hy vọng, sau khi ôn tập lại tất cả những chương đã đọc, thì 
bạn ít nhiều gì cũng hình dung được công việc của Tester là gì, và nó có 
khó như lúc đầu bạn đã từng nghĩ hay không? 
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CHƯƠNG 9: THÀNH PHÀN CHÍNH CỦA TESTCASE CƠ BẢN 
Ở chương này, tui sẽ giới thiệu cho bạn biết 1 testcase cơ bản nó sẽ 
gồm những thành phân nào? 
Thông thường khi viết testcase, mình sẽ sử dụng tool phổ biến nhất 
đó là excel. 
Tui sẽ diễn tả theo từng cột từ trái qua phải nha 
Cột đầu tiên là ID: Đây là số thứ tự của testcase 
Cột thứ hai là Deseription: Mô tả ngắn gọn về testcase đó 
Cột thứ ba là Pre-condiíion: Điều kiện cần để thực hiện các bước tiếp 
theo 
Cột thứ tư là Síeps: Các bước thực hiện 
Cột thứ năm là fesí Đa(a: Dữ liệu test 
Cột thứ sáu là Expeected Resuilí: Kết quả mong đợi 


Cột thứ bảy là Actual Result: Nếu đúng với kết quả mong đợi thì mình sẽ 
đánh PASSED, còn nếu khác hoặc sai với kết quả mong đợi thì mình sẽ 
đánh FAILED (đồng nghĩa với đây chính là BUG) 


Để thực hành thì tui sẽ có 1 bài tập nho nhỏ cho bạn để tập viết 
testcase thử nhé: 


Đề bài: Trang Sign up gồm: 


- Field Username: Từ 6 đến 15 ký tự (Không được nhập ký tự đặc 
biệt) 

-  Field Password: Phải có 1 ký tự số, ký tự hoa, và ít nhất là 7 ký tự 
trở lên. 

- Button Sign up: Sẽ được enable khi cả 2 fields ở trên có nhập 
thông tin. 

- Show message: Hiển thị thông báo thành công khi đăng ký thành 
công/ Hiển thị thông báo thất bại khi không thỏa mãn 1 trong những 
điều kiện được nêu trên. 


Trước khi qua trang tiếp theo, bạn thử hình dung trong đầu một 
testcase đăng nhập thành công cùng với Username có 8 ký tự nhai 


Ví dụ 1 testcase đơn giản liền nè: 
ID: 01 


Description: Kiểm tra đăng ký tài khoản thành công khi field Username 
được nhập ký tự trong khoảng từ 6 đến 15 ký tự. 


Precondition: Đang ở màn hình Sign up. 
Steps: 


- _ Nhập dữ liệu trong khoảng 6 đến 15 ký tự vào field Username. 
- - Nhập valid password vào field Password. 
- _ Click button “Sign up”. 


Test data: Username có 8 ký tự (Username là tester01) 
Expected result: 


- _ Đăng ký tài khoản thành công. 
- - Show thông báo thành công. 


Actual result: 
- PASSED. 


Kỹ thuật Phân lớp vùng tương đương được áp dụng đề viết testcase 
01 này! 


Cứ như vậy những testcase tiếp theo chúng ta sẽ áp dụng những kỹ 
thuật còn lại cho từng điều kiện được quy định cho mỗi field. 


Chúc bạn sẽ viết được nhiều testcase nhất có thể nhé! 


CHƯƠNG 10: VERIFY VÀ VALIDATE CÓ GÌ KHÁC NHAU? 
Nếu bạn xét về nghĩa của 2 từ này thì: 
Verify là chúng ta xác minh một vấn đề nào đó hay còn gọi là product right 


Validafe là chúng ta xác thực một vấn đề nào đó hay còn gọi là right 
product 

Vậy thì nó liên hệ gì trong software testing này? Chắc chắn là bạn 
đang rất là hoang mang và không biết phân biệt nó như thế nào đúng 
không? - Tui sẽ giải thích liền đây: 
Verify: Kiểm tra xem sản phẩm cuối cùng có thực hiện đúng yêu cầu của 
khách hàng hay không? 
Validate: Kiểm tra xem sản phẩm cuối cùng có thực hiện đúng cách đối 
với yêu cầu của khách hàng hay không? 
VD: Test tính năng đăng nhập của một trang web đơn giản. 

Verify xem tính năng đăng nhập này có đúng với yêu cầu với khách 
hàng hay không? 

Validate xem tính năng đăng nhập này có được thực hiện đúng cách 
hay không? Có đúng với nhu cầu sử dụng thực tế của khách hàng hay 
không? 


Hay bạn cũng có thể nhớ verification - product right/ validation - right 
product. 


CHƯƠNG 11: NHỮNG CÁCH TEST THƯỜNG DÙNG 


Ở chương này, tui sẽ tổng hợp cho bạn về những cách test thường 
được sử dụng trong quá trình làm việc thực tế: 


sRetest 
sRegression testing 
°Ad-hoc testing 
sSmoke testing 


sPerformance Testing (Stress/ Load) 


Bây giờ, chúng ta sẽ đi vào từng loại cụ thể nhé: 
RE-TEST: Là test lại tính năng để detect Bug theo: 


- _ †1 kịch bản testcase hoàn toàn khác kịch bản testcase trước đó 
- - † Phương pháp hoàn toàn khác phương pháp trước đó 
- _ Test trên cùng 1 build/ version giống nhau. 


REGRESSION TEST: Sau khi dev sửa bug xong, cần phải test lại để bảo 
đảm rằng việc sửa bug không gây ra sai sót nào khác. 





Nofe: Test lại bug trên bản build/ version mới. 


AD-HOC TEST: Là phương pháp kiểm thử theo dạng black-box, test không 
theo bất cứ loại kỹ thuật nào, test một cách ngẫu nhiên, gần như là dùng 
khả năng phân tích đoán lỗi theo kinh nghiệm của mình. 


SMOKE TEST: Là 1 quá trình để kiểm tra sơ lược liệu bản build có ổn định 
hay không? Để xem bản build có đủ ổn định để thực hiện tiếp tục test các 
phần chi tiết hay không (trong trường hợp bản build không ổn định, tính 
năng chính bị lỗi thì sẽ phải trả về Dev và yêu cầu fix ngay) 


PERFORMANCE TEST: Là kiểm thử hiệu suất dùng để kiểm tra độ chịu tải 
(Load Tesf) có khả năng chịu được khi có 1 lưu lượng lớn truy cập vào 
phần mềm hay không, và thời gian chịu tải của nó có ổn định, kéo dài 
được hay không (Sfress Tesi). 
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CHƯƠNG 12: TÔNG HỢP CÁC ĐỊNH NGHĨA VỀ DÒNG HỌ NHÀ TEST 
sTest Plan 

sTest Design 

sTest Scenario 

sTest Strategy 

sTest-Suite 

sTest-case 

sChecklist 

sTest Report 


Tui tạm gọi đây là dòng họ nhà Test, vì để trở thành một Tester thực thụ 
thì đầu tiên bạn sẽ phải nắm rõ và phân biệt được từng member trong 
dòng họ này. Nó sẽ rất giống nhau và cũng rất khác nhau. Nếu bạn đã bắt 
đầu thấy lùng bùng và rối não rồi, thì hãy bắt đầu dzô thôi nào: 


Test Plan 


#TEST PLAN ``ề 


à\ 
TY 010 ((100(0).)910000/210)01/-0//1-12 xòy 
J4121i801Ý/00/19119)/9)i-1efeF-[sfr-k 
Hã BI 210007109) 0 60-107 
LRIP(9/0190811-1900-IsŸ 
H190) 001010118 4151((0101 02 


LIIF-I8019)0)//-11)01/-0514[10810/o9.-1i 1 o7 
H97 (9110000807-151 109/-1)8¡-1/0)/-0.40|0l019 
cần test. 
LH 97-(9//19)81/0/0/0190)/200/0)0i9100000/-`-)i 
cần có. 
\- Test plan là cơ sở để test các 
V000 0000/01 001210077 
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Test Design 


` 
1181-5m0Ắ9)¬.¡:c ^ 


- Là tài liệu phác thảo những case 
©2I0N9/0//9)019)4I-1-1i97-1-1- 
lo 090/0) 09io) (1090 2 0(--(0....7 


- Đặc điểm: 

II 801110 8/9Ne)0/-1/Nei1-1:(0l¡i-¬ð 
010/2 I9Ter-(-1- To 2| coNo[› eo) (-), 
S10I-1eÃ - 

+ Ngắn gọn, dễ hiểu. 





` ` 
#TEST SCENARIO `. 


JÃI0i09U00 40 0) La 
- Test Scenario bao gôm tất o2 Ner.{e 
9016/e85Ÿ-]419l Noo 1á 1 e(0/e/e0.4|-1ii 0010104 


SN 0c 0)0/21/9002)(109/0/0/o029i9)0/-00I:)-: 

(®19)019)1/19)418/197201N--)00n9)-1-)|0))110 12 

TY Na 0i -(-000eo0i( 1-0 0/20/0000) ( 

II. )-0)/-0(0008/-09/-1e1/10)318410/9li19 

I//9)01981010/95Ã/-9Ÿ/> or-(ei140/0/0|9)18019/9 eie 

II1:9.€) AC No VL-NY(g|oNo|0|v19ïo[-10|9)NolV(e/e 
W8: 
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Test Strategy 


bo 
#TEST STRATEGỲ,)` 
` 


TA N(((9)000/-1(09)//-(e8:io 0/00 0/-00)002)00 0( 2 0Ú¡ 
01V 9-4019) 0e)0))/21714)4119)41-108//1-14089)272)0 
mềm. 
2) 0(oio0r-I9 (209/20/0109 100 -.(of0o.: (1o (choi 
s0. NA(-1-1(-10009/-1/-1io)9)-100)//-0//loì 0-00 //-Ì, 
9[2E90)10)4 9 VI No|ì/-0/0Ì13148/41-10) 815192 
1-9000 
GÌ /I0Iel¡121 08 41-1(:8/(10/00127-1(000)210/0/0|9100)./-10 
90)019N9[> 4121448410 i09r-1ofola10/e8:7-131e180016/ï 
I9)01981019/IN9112148Y/-8/191119)0080)57-141819/e19/e/e 
XS yêu cầu cho dự án kiểm thử 





Test Suite 


- _ Là tập hợp một hoặc nhiều testcase có cùng chức năng hoặc có liên 
quan với nhau. 


Testcase 


LAN -©7 V.1- 


Ni (o0/70(0 (90 09/0đ)/2009/21 000 Ï//-1e 
(019)019041-151:0oio)ai9ll((0i19)4)083i97o1e 


M1918-106 4100 0(- /-0 00000 ï (20 ‹(-i00|0 2 
00M A ¿I0 (-).491-1eii-i910/-1-19ie)0)-.-)N 

KV (6-1 0/072100008 4/210 (0l l¡((-0(90/ 019 
el01Ý/(e4[-IaIoNeiVF-00/nls0oi0js|eNolsfoji 
IMT>108/197i09ie)01e1elíIs[1eBa[) 21 .4419)319Ƒ 
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Checklist 


>> 
¡201i i®i 45L. XI _- 


ñ -0000900°9/-00000-.- (0o. sáo 0ì0)0,5 
9910/e04I2)019/2219)4).190//0092)008 4-10 
IIf20//9)3190/19)/8/41081010Ä47-0/1510)/09)|014 


0IIFIeIlsÌif 

AI 909)1 009 Ã(-1-:21007-)00110/21e02)0/-ì: 
6I0/e/el(©)419Iá1-for-1o o0) (ola†|iïe 
I0/9)41911/191/19)9)|10/07/-0o[\010Noj[-' 
6I9/9/9100/9/0198516i90n 211-812 0m 21) 82 
NI 200, )-1e4)1-10-1-09i0/(o/c00i6ie 
tách chia thành nhiều testcase. 





Test Report 


fTEST REPORT 


N00 0(00(9000/210010//000)(0)(0 0072 
00IP2I180/1200/85197-I9E-7-1489)072)0/8017-) 


9i Ne[z1019I 0-1047 

TY €1 /90:10ig1o)0)9109)0/o/o9:)010/( 19109) 
SE-RF-10/NeI0/9/901/9)019184/19)18.40197-1019 
I0019/N9I1-108514-1109i|9148 
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Như ở những chương trước tui có đề cập, để phát hiện ra được con 
bug thì phải cần vận dụng nhiều kỹ năng cũng như kỹ thuật. Vậy sau khi 
phát hiện ra con bug rồi, thì làm cách nào để biết nó có nghiêm trọng hay 
không, nó có cần phải ưu tiên fix trước hay không. Thì sau đây, xin mời 
bạn tiếp tục qua chương tiếp theo... 


CHƯƠNG 12: PHÂN BIỆT PRIORITY VÀ SEVERITY 


Đầu tiên chúng ta cùng nhau tìm hiểu về Severity nha 


+#SEVERITY 


KTS /-10I0/ð1L>90/11/e9120-101401//0/419f00[-0=101€AY/(0/N-1(16)ã/-1100141-100/19721001972100919)/19100191-002116) 
[0I01019/N9E-1/19/01-1-1000)/111019i9-14)1018010/64519)819/I097-1oÐm0)))1@101)))0e721i1o)0er-(o0(3110-1=\ A= n0 4 

[0 >119JTt7(9 NN-'-(-1//0672040)//04019181-10/19)0/0419.(-1019))0108-1-)/4-)01012 

Ti (0 0007210-121//10)\/- 

LI91/0111e7-1019)-1/-i910 4011212109: 1900/1-1410/0)41218:197-100919)/19)00101-00197212009)412100/4)1-10/1/0)00019102019)00197210 
I91-1I00 491014191 919)0109)4†21008/121 09 190101-106)2T-)/0101)/40,eŸ 

K\(Ÿ11910119J-3(-10100516)a]1>10)149)/1e 1 Tio00i/1-6L210-7-100.1-10i/121219180)v)1201910e:61//19107-10100)472101 427.16 
N/Z10Ñ0|972111919)11191ể9)1/19195 

K4 Y/L-1s1171i( DJ -1/-100e†-ì Ar-0i[o)g- 1o No >1) /0199Ÿ-1001519)a1ejlo|s20Na)(10//191821201210)0190//-11184197-1: 
l[9)8I9E 

Dị o1 ì/21Đ)-1/-1010.4019)019)09/2)/0g20o7-ì0.408-)0119io0io/4i0i:-(o0o0io09(1-0(019)3197 

D9 .1⁄,0‹-.ic09ii/)(0-1- /(- 0ì 0 2` 

MP) )/-1/-108121408-10/-110.4)/-110/1/21/H)|-)01009)-11-1e00n)01o00i10)104019/0/0)0/94119)9.{-)/01/-10912)/01-1010/0/10402019) 
H0)9/94019/9.40)/-11)010110016109/9)0/41-119101ã91908219)0]1-10)1/9)319J o.-1eÐ 

MP) I-Ñ1(2)/8-1/.0995/-I905/-1/-1s009/9ÄL2)s9)-)i-1eifois (0) -0e)I(19001)0/)0/-0//10/009/00/19)0)1-10/)80/6)019) 
HẠI>1967-1019)0910/94)091-0 2: 


7O) l0 0000 lAÀ Án. 2 


Severit 


Critical Non-Critical 


ty 


Urgent 


Key feature C 
does not work s ng 


PrIOFi 
Low 


7O) l000),)lAÀ Án -L-+ 





Dựa vào bảng này, chúng ta sẽ kết hợp giữa 2 tiêu chí Priority và 
Severity để mà kết luận rằng con bug này cần phải fix nó trước hay fix nó 
sau. 


Mà Priority là gì? 


+PRIORITY 


Priority là thứ tự cần xử lý defect. Priority càng cao nghĩa là defect 
(021019 ec10)N9)019/059)1-18910)/-118-1040/1031019)419/011))/042019/84)0)0/4010000.-1/- 00 -00)0 

0] 0000199] 210)80197-110919)019)00[- To -0u|-0i119)0198-1-00/0/o 1027/00 ¡1-12 1001-1e0i140)8/14104019) 
lðI23/>10iN9ý[- We:-1e e0] (el47-1019)85)0167 
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Đến đây, bạn sẽ rất thắc mắc, vậy mình sẽ kết hợp nó như thế nào. 
Nếu như độ severity nó cao, mà priority nó thấp thì sao? hay ngược lại 
severity nó thấp, mà priority nó lại cao thì làm thế nào để biết mà nhận biết. 
Khá nhiều suy nghĩ trong đầu của bạn lúc này phải không? Không để bạn 
phải đợi lâu, tui sẽ đưa ra một vài ví dụ để bạn hiểu rõ hơn: 
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Nhìn vào những ví dụ trên, thật là dễ dàng để mà hiểu rõ sự kết hợp 
giữa severity và priority phải không bạn. Tui cũng xin nói thêm, trên thực 
tế, khi Tester log bug lên hệ thống thì chỉ cần xác định cho nó độ severity là 
được rồi, còn priority thì có thể là sự sắp xếp phân công của Leader. Tùy 
thuộc vào tình hình của dự án mà Leader sẽ sắp xếp con bug này có độ ưu 
tiên như thế nào. 


Tuy vậy, nhưng bạn vẫn cần phải biết độ ưu tiên của nó như thế nào 
phòng trường hợp những member khác đôi khi nhận định sai hoặc lãng 
quên nó, thì mình còn có cơ hội mà thể hiện chứ! 


CHƯƠNG 13: 13 LOẠI BUG THƯỜNG GẶP 


Ngoài những kỹ thuật thiết kế testcase, ngoài những kỹ năng đoán 
lỗi, ngoài những kinh nghiệm tích lũy được thì tui cũng muốn giới thiệu đến 
bạn về 13 lỗi cơ bản thường gặp trong cuộc đời của mỗi Tester. Nếu như 
biết về nó, thì việc miss bug là điều được hạn chế đi rất nhiều. Vậy nó là 
những loại nào, cùng nhau coi qua nha, ok dzôH! 


- User lnterface: UI (giao diện) 


- Error Handling: Xử lý lỗi (Thông báo lỗi không đầy đủ, rõ ràng/ Thông 
báo sai) => Dựa vào requirement để so sánh. 


Ví_dụ: khi nhập sai thông tin email khi login thay vì hiển thị message bạn đã 
nhập sai email hoặc password thì nó lại hiển thị bạn đã nhập sai email. 


- Boundary - Related: Giá trị biên. 
- Calculator: Tính toán. 
- Initial and Later States: Giá trị khởi tạo và giá trị sau khi thực hiện xử lý. 


Ví dụ: Form tạo thông tin cá nhân cá field nhập ngày tháng năm sinh, kiểm 
tra xem kết quả ngày sinh sau khi tạo form có hiển thị giống như lúc mình 
nhập ban đầu hay không. 


- Control Flow: Luông xử lý (Ví dụ: bị gián đoạn 1 giai đoạn nào đó). 





- Handling or Interpreting Data: Import và Export dữ liệu. 
- Race Condition: Trình tự của các xử lý (Trình tự xử lý không đúng). 


- Load Condition: Quá tải. (Để biết được lỗi này thì bạn phải nghiên cứu 
thêm về Load Test/ Stress Test của Performance Testing) 


- Hardware / Environment Compatibility: Phần cứng/ Phần mềm. 
- Source, Version, ID control: Phiên bản (Update sai phiên bản). 
- Testing: Lỗi do Tester. 


- Documentation: Tài liệu. (Tài liệu bị sai yêu cầu) <= đây cũng là một 
trong những kỹ năng đầu tiên của Tester, cần phải biết phân tích document 
trước khi bắt tay vào viết testcase. 


Lời kết 
Hy vọng rằng với những kiến thức cơ bản trong tập tài liệu này sẽ 
giúp bạn hiểu được một phần nào đó về Tester cũng như công việc test 
một cách đơn giản và rõ ràng nhất. 
Bạn có thể tìm hiểu nhiều kiến thức hơn trên Fanpage Kiến Thức 
Tester - Testing Sharing nhé! 


Thân chào!!! 


